With the emergence of network-connected devices, and particularly with the growing importance of ensuring uncompromised operation of such devices, a growing need for establishing trust is required. In a network of devices, it is difficult to establish that a message originated from a device that has not been tampered with or compromised. In such a network, an attacker may wish to tamper with a device in order to send out data advantageous to the attacker. For example, in a network-based home security system, one node may verify the identity of the person attempting to open the door, and another node may open the door, relying on the data from the verifying node. In this case, while the attacker may not be able to provide the proper credentials to identify themselves as a person authorized to enter the home, they may instead be able to compromise the verification node. The compromised verification node then transmits a message to the node responsible for opening the door, and, because the verification node is compromised, it may falsely transmit a message indicating that the attacker is authorized to enter the home.
In order for the receiving node (in this example, the node responsible for opening the door) to verify that the sending node (the verification node in this example) has not been tampered, the receiving node would need some way of inspecting the software present on the sending node. Because the receiving node has no way to actually inspect the sending node to make sure that the software on the sending node has not been tampered, the receiving node can not reliably tell the difference between messages sent from a compromised sending node as compared to those sent from an uncompromised sending node.
One difficulty stems from the general fact that there is software involved on the sending node, and that this software can lie if compromised about various authenticating factors. For instance, since all of the data sent from the sending node generally passes through software, this means that data used to indicate the non-tampered status of the sending node can be faked by tampered software. For example, in one such scheme, the sending node and the receiving node mutually authenticate each other, and establish a token, be it a simple number or an encryption key, to be used for future communications. Generally, receipt of the token indicates that the sending software has not been tampered. This may be achieved by existing hardware-based solutions, such as ones based on Trusted Execution Environment modules as are known in the art. However, once the token is known, an attacker can then modify the software on the sending node, causing it to send out the same token, even thought the software is tampered. This negates the effectiveness of any scheme based on tokens that pass through software.
The net effect of this is that, to the receiving node, the sending node is a black box whose veracity cannot be established by the receiving node.
In general, various existing methods purport to establish the veracity of the sending node, by such means as establishing a hardware root of trust, such as secure bootloaders. However, these solutions have significant drawbacks as they generally invoke the use of software to transmit their data. Accordingly, if the software is tampered, it can fake messages that are otherwise indistinguishable from messages originating from untampered software.
This background information is provided to reveal information believed by the applicant to be of possible relevance. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art.